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(54) Method and device tor IP muitlcast over a broadcast ctiannel 



(57) A method of and apparatus for providing an In- 
ternet Protocol multicast service wherein multicast data 
is transmitted through multicast routers (8) to user sta- 
tions (9) over a digital broadcast channel (especially 
DVB-T) together with digital broadcast signals, at least 
If a request has been received from a user station (9) 
for the multicast data,. The transmission of the multicast 
data by a multicast router is conditional upon the recep- 



tion of a request for said multicast data from that multi- 
cast router by a plurality of the user stations (9). The 
number of requests from the user stations (9) has to be 
greater than a threshold number, which Is a function of 
the available bandwidth for multicast transmission over 
the broadcast channel. Infomiatton concerning the re- 
quests for the multicast data by the user stations (9) is 
unavailable to the other user stations (9). 
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Description 

Field of the invention 

[0001] This invention relates to the transmission of an 
Internet protocol ('IP') multicast service over a broadcast 
channel. 

Background of the invention 

[0002] The most common type of IP communication 
Is a unicast communication, that is to say In which the 
communication Is established between nodes whose In- 
dividual addresses are Identified in the datagrams trans- 
mitted. If a server is to send the same datagrams to more 
than one address, it must repeat the datagrams with 
each individual address. The unicast method of trans- 
mission is accordingly ill suited to mass distribution of 
messages or other communications to many destina- 
tions. 

[0003] To meet the requirement for transmitting inter- 
net communications to many destinations, a modified 
protocol is available for multicast services. IP multicast- 
ing is the transmission of an IP datagram to a "host 
group", a set of one or more hosts identified by a single 
IP destination address, A multicast datagram is deliv- 
ered to all members of its destination host group with 
the same "best-efforts" reliability as regular unicast IP 
datagrams. I.e., the datagram Is not guaranteed to arrive 
intact at all members of the destination group or in the 
same order relative to other datagrams. The member- 
ship of a host group Is dynamic; that Is, hosts may join 
and leave groups at any time. An IP module may only 
receive datagrams if it has previously sent to the host a 
request to join the group. There is no restriction on the 
location or number of members In a host group. An In- 
coming datagram destined to one of those groups is 
processed exactly the same way as datagrams destined 
to one of the host's individual addresses. Incoming da- 
tagrams destined to groups to which the host does not 
belong are identified by the group address and discard- 
ed without generating any en'or report or log entry. 
[0004] Digital broadcasting, and in particular digital 
television, is another service enabling the transmission 
of programmes or other communications to many des- 
tinations over cable connections or satellite or terrestrial 
wireless electromagnetic transmissions. Broadcasting 
differs from IP transmission in that the communication 
is essentially unidirectional; if Interaction is desired with 
the destination, the response of the destination must be 
through a different link, such as the Internet or telephony 
communications. Each transmission on a given channel 
reaches ail receivers connected to that channel. 
[0005] Data streams additional to the broadcast serv- 
ices may be transmitted over the same broadcast chan- 
nels ('encapsulated'). Multicast services may therefore 
be transmitted In one direction with the broadcast serv- 
ice and this is a convenient method of providing IP mul- 
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ticast services. One such method is described in the 
l\4ultimedla Car Platform (MCP) project described at the 
Internet site http://mcp.fantastic.ch/ . Another method Is 
described in international Patent Application specifica- 
5 tion publication N'* WO 00/48361 . 

[0006] It is desirable to economise on the usage of 
transmission bandwidth ('spectrum') for multteast serv- 
ices transmitted together with digital broadcasts. 

10 Summary of the Invention 

[0007] The present invention provides a method of 
and broadcasting apparatus for providing an Intemet 
Protocol multicast service over a broadcast channel as 
IS claimed In the accompanying claims. 

Brief description of the drawings 

[0008] 

20 

Figure 1 is a schematic diagram of a system for pro- 
viding Internet protocol services over a broadcast 
channel, 

25 Figure 2 is a schematic diagram of a system for pro- 
viding multicast services over Internet infrastruc- 
ture. 

Figure 3 Is a schematic diagram of a system for pro- 
30 viding Internet protocol multicast services over a 
broadcast channel in accordance with one embod- 
iment of the Invention, 

Figure 4 is a schematic diagram of a system for pro- 
35 viding Internet protocol multicast sen/ices over a 
broadcast channel in accordance with another em- 
bodiment of the invention, and 

Figure 5 is a flow chart of exchanges of messages 
40 in operation of the system of Figure 4. 

Detailed description of the preferred embodiments 

[0009] Figure 1 shows apparatus for transmitting In- 
45 ternet protocol datagrams over a digital video broadcast 
networi<. The broadcast networic comprises transmitter 
apparatus, including aerials 1 , each covering a respec- 
tive broadcast cell 2 defined by Its operating range, in 
this embodiment of the invention, the broadcast system 
so is a digital television broadcasting system, in accord- 
ance with the European Telecommunications Standard 
Institute ("ETSI"), although other broadcast standards 
may be used in other embodiments of the invention. The 
particular system Illustrated Is a terrestrial broadcast 
55 system according to the standard DVB-T, but it will be 
appreciated that the invention is also applk:able to 
broadcast from satellites or over cable systems, for ex- 
ample, as well. The system includes a source of televi- 
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slon signals, Including video and audio content and as- 
sociated signal infonnation and the transnnlssion from 
an aerial 1 to receivers or user temninals 3 is unidirec- 
tional. 

[0010] The system is also connected with Internet in- 
frastructure 4 that can generate "private data** in the 
fomn of data carousels or IP datagrams for transmission 
over the broadcast network. The broadcasters' equip- 
ment includes a network 5 of internet terminals connect- 
ed with the Internet infrastructure 4. The broadcasters' 
network of temninals 5 and the network of broadcast 
transmitter equipment. Including the aerials 1 are inter- 
connected through gateways 6 that encapsulate the IP 
traffic into the stream of MPEG2 signals for the televi- 
sion in accordance with the DVB specification for data 
broadcasting ETSI EN 301 192 v1.2.1 and the Imple- 
mentation guidelines ETSI TR 101 202 1 92 V1 .1 .1 . 
[001 1 ] Depending on the choices of the broadcaster, 
the IP/DVB gateways 6 can encapsulate the IP In the 
broadcasts for different sizes of areas, including one or 
more broadcasting cells. Ail the user temiinals 3 within 
an area served will be able to receive the same IP pack- 
ets coming from the same IP/DVB gateway 6. To reach 
a user through the broadcast link, an IP packet must be 
routed to the IP/DVB gateway 6 that serves the area in 
which the user is located. 

[0012] Referring now to Figure 2, the Internet infra- 
structure 4 Includes apparatus for providing IP multicast 
services using IP multicast protocols in accordance with 
the Internet protocol version 4, although it will be appre- 
ciated that other Internet protocol versions could be 
used in accordance with the Invention. The IP multicast 
protocol enables IP datagrams to be transmitted from a 
source to many destinations using a single multicast ad- 
dress. To support multicast, the network entities need 
some minor adaptations. 

[0013] The infrastructure for effecting multicasts over 
the normal Internet typically Includes a multicast server 
7, and multicast routers 8 that supply multicast commu- 
nications to clients 9. In operation, the multk:ast server 
7 begins by announcing the multicast session, the an- 
nouncements being made using multicast protocols 
such as the session announcement protocol ("SAP") ac- 
cording to the cun-ent text of the Intemet engineering 
task force ("IETF") standards, for example, through e- 
mail, newsgroups, web pages or directories. A host that 
wishes to be a client for such a session must subscribe 
to a local multicast router 6 using the Internet group 
management protocol ("IGMP"), of which version 3 is 
IETF version 6, the internet group management protocol 
including two-way communication as shown In Figure 2. 
Each multicast router will broadcast the multicast ses- 
sion in all the sub-network that It serves if at least one 
user has subscribed. 

[0014] In multicast communication overthe nomnal In- 
ternet structure in accordance with the current text of 
the IETF standards, in order to avoid unnecessary ex- 
changes of messages as users subscribe to a given 
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multicast session, the message from a multicast client 
9 subscribing to a session is sent to Its muttbast router 

8 by IGMP protocol during a subscription period and is 
also broadcast to the other users in the sub-network 

5 served by that multicast router 8; the other users served 
by the same sub-network receive the subscription mes- 
sage of the first subscriber and are then Inhibited from 
sending their own registration messages. 
[0015] The multicast routers B accept all multicast 

10 messages to specific addresses (222.0.0.1 and 
222.0.0.2) that are reserved for multk;ast communica- 
tion. Once a message has been received for registration 
of a multicast client 9 and the time of the multicast ses- 
sion arrives, routing protocols and algorithms select all 

IS the sub-networks where the multicast datagrams are to 
be propagated and in which at least one multicast client 

9 Is known to have registered In order to receive the mul- 
ticast packets. 

[001 6] it will be appreciated that the connections be- 

20 tween the multicast routers 8 and the multicast clients 
9 over the normal Internet infrastructure may include a 
point-to-point connection or a connection supporting on- 
ly unicast services. Accordingly, it is still necessary to 
duplicate packets downstream of the multicast routers 

25 8. Communication ofthe multicast data over a broadcast 
link, on the other hand, would avoid a requirement for 
any duplication of packets. Also, a broadcast link can 
offer a large and guaranteed bandwidth for the trans- 
mission of multicast services. In addition, the quality of 

30 service offered by a DVB broadcast is assured once the 
service has begun overthe broadcast transmission sys- 
tem. Accordingly, it is desirable to be able to offer mul- 
ticast sen^ices over broadcast networks, such as the 
DVB broadcast network illustrated in Figure 1 . 

35 [0017] In the normal Internet infrastmcture, if there Is 
even only a single user subscribed, a muttlcast service 
is always assured once the service has been an- 
nounced but from a "best effort" philosophy: that is to 
say that packets are transported to the user as and when 

40 possible and the availability of sufficient bandwidth is not 
checked, so that the service received by the user may 
in fact be insufficient. 

[0018] However, in the present embodiments of the 
invention, the available bandwidth ofthe DVB broadcast 

^ network for multrcast services does not enable all pos- 
sible sessions to be broadcast and it Is necessary to be 
selective. In particular, the offer of multicast services 
overthe broadcast transmitter network is conditional up- 
on the availability of sufficient transmission resources 

so for each multicast session and upon the number of users 
successfully registering for the multicast session, a re- 
turn path being provided for registration of multicast cli- 
ents 9, which is necessarily over a different link from the 
broadcast transmissions, given the unidirectional nature 

55 of the latter. More multicast sessions may be announced 
than are expected to be transmitted In fact ultimately at 
the proposed times, the selection of which sessions to 
broadcast being made as a function of the resources 
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available in a given DVB area and tiie number of muiti- 
cast clients 9 subscn'bing to the session in that area. The 
broadcaster may choose whether to cancel or postpone 
sessions that he decides not to broadcast as an- 
nounced. 

[001 9] Another feature of the present embodiments of 
the invention is that the protocol enables more than one 

multicast client served by a given multicast router 8 to 
register for a given multicast session and, indeed, an 
incentive is provided tor ail users interested to register, 
in order to obtain as accurate a measure as possible of 
the demand for each particular multicast session pro- 
posed. 

[0020] In the embodiment of the invention shown in 
Figure 3, the network 10 of DVB-T transmitters is sup- 
plied with IP and DVB data through the gateways 6, 
which also serve as multicast routers B. Each of the mul- 
ticast clients 9 has an interactive linic 11, which is en- 
sured by a telecommunications link according to the 
UIVITS standards in the preferred embodiment of the in- 
vention, although return links to other wireless commu- 
nication standards or through fixed line communications 
are also possible. The multicast services are transmitted 
over the DVB-T network 10 in response to registrations 
made by the multicast client 9 using the IGMP protocol. 
[0021] In this embodiment of the invention, the com- 
munication of the multicast client 9 with the gateway and 
muttk;ast router 6, 8 over the return link 11 in ensured 
as a lunnei" 1 2 using the unidirectional link routing pro- 
tocol ("UDLR") described in IETF RFC3077. 
[0022] This standard is intended to enable the use of 
standard Internet protocols over unidirectional links, 
such as DVB, sothatthe unidirectional network behaves 
like a standard Internet bl-dlrectlonal network. Multicast 
session announcements are broadcast over the unidi- 
rectional broadcast link. Responses from the multicast 
clients 9 are then returned to the IP/DVB gateway and 
multicast router 6. 8 through the interaction link 11 . For 
this purpose, the IP address of the gateway is broadcast 
to all DVB receivers using the unidirectional broadcasts 
with the dynamic tunnel configuration protocol specified 
in UDLR. 

[0023] In accordance with the current text of the UD- 
LR standard, since the DVB receivers cannot commu- 
nicate directly with other nodes In the same sub-net- 
work, the DVB gateway and multicast router 6, 8 would 
broadcast the registration messages it has received 
over the DVB broadcast. However, in accordance with 
this embodiment of the present invention, the iP/DVB 
gateway and multicast routers, 8 blocks the registration 
messages that it receives and does not broadcast them 
over the DVB broadcasts. Each multicast client 9 there- 
fore has an incentive to register for any multicast ses- 
sion that he is interested in, in order to increase the 
chances of the multicast session actually being broad- 
cast as announced In the broadcast area he receives. 
It is therefore possible to count the number of responses 
received for each IP/DVB gateway and multicast router 
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6, 8 and this number can be used to Judge the impor- 
tance and value of broadcasting a particular multicast 
session in that area and to decide between different ses- 
sions if insufficient broadcast resources are available for 

5 broadcasting them ail. 

[0024] In addition to the responses of the multicast cli- 
ents 9 before the broadcast of a given multicast session, 
the IGMP protocol also implements a "query" message 
whereby the user stations are repeatedly interrogated 

10 during the course of the session and respond automat- 
ically If the session is still being received. This query Is 
also implemented in the present embodiment of the 
present invention by responses over the Interactive link 
11. 

IS [0025] In both cases, it is necessary for requests for 
the multicast sessions or responses confimiing contin- 
ued connection with the multicast session to be received 
from a sufficient number of the user stations, the multi- 
cast clients 9, at a given tP/DVB gateway and multicast 

20 router 6, 8, for that gateway and multicast router to 
broadcast a multicast session or to continue broadcast- 
ing it. 

[0026] If the multicast session broadcast is cancelled 
or postponed, the users are warned by sending the ses- 
25 sion announcement protocol cancellation messages 
that are specified in IETF RFC2974. If the user still wish- 
es to receive the multicast service, he may then attempt 
to access the service through a different multicast serv- 
er. 

30 [0027] The embodiment of the present Invention 
shown in Figure 4 includes a DVB-T network 1 0 includ- 
ing transmitters 1 , linked with the Internet infrastructure 
4 through a broadcaster IP network 5, with IP/DVB gate- 
way 6 providing the Interface between the broadcaster 

35 IP network 5 and the DVB-T network 1 0. The Internet 
infrastructure 4 includes multicast server 7 and multicast 
routers (not shown in Figure 4, 
[0026] The broadcaster IP network 5 also includes 
multicast manager units 1 4 that are linked with the mul- 

40 ticast server 7 and multicast routers and with the IP/DVB 
gateways 6. 

[0029] An interactive uplink 13 is provided from the 
mobile temninais 9 to the multicast managers 14, pref- 
erably through wireless communication according to the 

45 GPRS, WUVN or UMTS standards. 

[0030] Responses of the multicast clients 9 register- 
ing for a multicast session are addressed to the specific 
multicast service addresses of the multicast managers 
14 together with infomnation concerning the gateway 6 

so from which they receive session announcements using 
the session announcement protocol. A multicast man- 
ager 14 controls the transmission of a multicast session 
through a plurality of IP/DVB gateways 6 as a function 
of the number of multicast clients 9 registering for that 

55 session for transmission through the respective gate- 
ways and the transmission of the multicast session at 
each gateway 6 is conditional upon the reception of re- 
quests for the session at that gateway from a sufficient 
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number of user stations served by that gateway. 
[0031] In nfiore detail, each multicast manager 1 4 re- 
ceives from the multicast server 7, lil<e any other user 
in the Internet, announcements of forthcoming multicast 
sessions using the session announcement protocol, 5 
which It stores In a cache in the fonn of a multicast ses- 
sion directory service. The multicast manager 1 4 inserts 
the session description as a session description proto- 
col according to the current text of the IETF standard 
RFC2327 into the stream of data broadcast from each 
of the iP/DVB gateways 6 that it controls, which Is re- 
ceived by the mobile temninais 9 served by that multicast 
manager. Conditionally upon the reception of a number 
of requests from multicast clients 9 sen/ed by the differ- 
ent iP/DVB gateways 6 being greater than a threshold 
number, the multicast manager causes the con^espond- 
Ing gateway to subscribe to the conresponding multicast 
session. The threshold number Is a function of the re- 
sources available for broadcasting that session from the 
gateway 6 concerned and is set so as to exclude any 
other multicast session that has fewer subscribers and 
would cause the bandwidth utilisation to exceed the re- 
sources available for multicast sessions. 
[0032] Once again, the user stations are preferably in- 
terrogated repeatedly during the course of multicast 
sessions so as to check that there are still sufficient mul- 
ticast clients subscribed and the continued transmission 
of the multicast data Is conditional upon the reception of 
responses from a sufficient number of multicast client 
stations. 

[0033] The responses from the multicast clients 9 are 
transmitted over the interactive link 13, which is con- 
nected to the internet infrastructure 4 for onward trans- 
mission of the responses to the multicast managers 14. 
These responses are not retransmitted to the other mul- 
ticast clients 9. Accordingly, the multicast clients 9 have 
an incentive to registerfor a given multicast session and 
the number of registrations received Is a reliable meas- 
ure of the potential demand for a given session. 
[0034] Figure 5 shows a flow chart of the exchanges 
of messages between the multicast server 7, the multi- 
cast managers 14, the gateways 6 and the mobile 
nodes, or multicast clients, 9. In this example, the prep- 
aration for broadcast of a multicast session starts with 
the session announcement using the session an- 
nouncement protocol and including a description ac- 
cording to the session description protocol as shown at 
15. The session announcements 15 are made at a mul- 
ticast address that is generally known and with a port 
number that identifies the announcement protocol used 
(SAP In this example). The announcement 15 is broad- 
cast during the period ("time to live") preceding the ses- 
sion to which it relates and is communicated to the IP/ 
DVB gateways 6, which transmit the announcements 
without interpreting them. 

[0035] The multicast session directory service tool of 
the multicast managers 14 enables the multicast man- 
agers to maintain a list of all session descriptions that 
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have recently been announced and to send a list of 
available sessions for each gateway 6. Infomnatlon as 
to the identity of each gateway 6 and its associated mul- 
ticast manager address is included in the broadcast an- 
nouncement so as to enable the user to respond to the 
multicast manager 14 corresponding to the gateway 6 
that serves that multicast client 9 and this inf onnatlon is 
transmitted from the multicast manager 14 to the rele- 
vant gateway 6, as shown at 1 6. The multicast manager 
14 checks whether the multicast sessions announced 
by the multicast server are intended for the area covered 
by the partbuiar gateway 6 and only forwards those ses- 
sions that are. The selected session announcements 
1 7, together with the multicast manager infomiation, are 
then broadcast over the DVB transmitter network 1 0 to 
those multicast clients 9 within the area of the networic 
10 covered by the relevant gateway 6, in the manner of 
a data carousel. In the preferred embodiment of the in- 
vention the announcement 1 7 Is made using the an- 
nouncement support descriptor described in the DVB 
sen/ice information of ETFI EN300 468 V1 .4.1 , although 
it would also be possible to transmit the information in 
the DVB stream using other IP over DVB encapsulation 
mechanisnfTS. 

[0036] Each multicast manager 14 receives infomia- 
tion concerning the bandwidth available for private data 
in the broadcast area fed by each of its DVB/IP gate- 
ways 6 that it controls. It controls the broadcast of a giv- 
en multicast session at a given IP/DVB gateway 6 as a 
function of the number of responses it receives from 
multicast clients 9 served by that particular gateway as 
identified in the responses. 

[0037] The user at each mobile terminal 9 can browse 
infomnation received concerning the different multicast 
sessions available and subscribe to It by sending the 
identification of the session together with the identifica- 
tion of the location of the user, that is to say the identity 
of the gateway 6 that transmitted the announcement to 
him; the response is communk;ated to the address of 
the multicast manager indicated in the announcement 
as at IB. In an alternative embodiment, the location in- 
fonmation of the mobile terminal is given by the identifi- 
cation of the DVB broadcast cell, which enables the mul- 
ticast manager 14 to identify the gateway serving the 
user. 

[0038] If the number of user subscriptions is greater 
than a threshold that excludes the superfluous multicast 
sessions for that particular area of the DVB transmission 
network 10, the multicast manager informs the corre- 
sponding DVB/IP gateway 6 to subscribe to the multi- 
cast session, as at 1 9. The iP/DVB gateway 6 then sub- 
scribes to the multk:ast session using the IGMP protocol 
as at 20. When the multicast session begins, multicast 
data is then communicated from the multicast server 7 
to the IP/DVB gateway 6 as at 21, and passed to the 
transmitter network 10 where it is encapsulated as pri- 
vate data and transmitted over the transmitters 1 to the 
multicast clients 9. as shown at 22. The multicast clients 
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9 in the area of the transmitter network 1 0 served by that 
gateway 6 may then receive the multicast session at the 
corresponding multicast address, 
[0039] While a multicast session is being broadcast, 
the DVB/IP gateways 6 continue sending further ses- 
sion announcements generated by the multicast man- 
ager 14 at regular intervals over the DVB transport 
stream and stop only when the session is finished or Is 
cancelled by the broadcaster. If the broadcaster cancels 
the multicast session, the multicast manager 14 halts 
the con^esponding announcement and generates a ses- 
sion cancellation announcement using the session an- 
nouncement protocol. 

[0040] In the prefen-ed embodiment of the invention, 
the multicast clients 9 implement an implicit time-out for 
the session: if a session announcement message is not 
received during a predetemnined period since the pre- 
vious session announcement, the tenminal considers 
that the multicast session has been cancelied without 
waiting for reception of the session cancellation an- 
nouncement and can immediately attempt to receive the 
multicast service through an alternative multicast iinic. 



Claims 

1 . A method of providing an Internet Protocol multicast 
service wherein multicast data is transmitted 
through multicast routers (8) to user stations (9) 
over a digital broadcast channel together with digital 
broadcast signals, at least if a request (1 8) has been 
received from a user station (9) for the multicast da- 
ta. 

characterised In that the transmission of said mul- 
ticast data (22) by said multicast router is condition- 
al upon the reception of said request (1 8) for said 
multicast data from said multicast router by a plu- 
rality of said user stations (9). 

2. A method as claimed In claim 1 , wherein the trans- 
mission of said multicast data (22) by said multicast 
router is conditional upon the reception of a number 
of said requests (IB) from said user stations (9) 
greater than a threshold number, said threshold 
number being a function of the available bandwidth 
for multicast transmission over said broadcast 
channel. 

3. A method as claimed in claim 1 or 2, wherein said 
user stations (9) are repeatedly interogated and 
the continued transmission of said multicast data 
(22) by said multicast router is conditional upon the 
reception of responses (18) from a plurality of said 
user stations (9). 

4. A method as claimed in any preceding claim, where- 
in information concerning said requests (18) for said 
multicast data from said user stations (9) Is unavall- 
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able to the others of said user stations (9). 

5. A method as claimed In any preceding claim, where- 
in said signals and data are transmitted through 

s gateways (6) between Intemet and broadcast infra- 
structures (4, 5 and 1 0) to respective broadcast ar- 
eas and the transmission of said multicast data (22) 
within a broadcast area by the corresponding gate- 
way (6) is conditional upon the reception at that 

10 gateway of said request (1 8) for said multicast data 
from a plurality of said user stations (9) served by 
said broadcast area. 

6. A method as claimed in any preceding claim, where- 
is in announcements (17) of future multicast data 

transmission sessions are transmitted to said user 
stations (9) over said broadcast channel. 

7. A method as claimed in claim 6, wherein said re- 
20 quests (18) for said multicast data from said user 

stations (9) are received by said multicast manager 
station (14) over a link different from said broadcast 
channel and said multicast manager station (14) 
controls the transmission of said sessions as a tune- 
rs tion of the number of said requests (18) from said 
user stations. 

8. A method as claimed in claim 6 or 7, wherein an 
announcement of cancellation of a future multicast 

30 data transmission session or of temiination of a cur- 
rent multicast data transmission session is transmit- 
ted to said user stations (9) over said broadcast 
channel. 

35 9. A method as claimed in any preceding claim, where- 
in said user stations (9) respond to said multicast 
data over a communication link different from said 
broadcast channel using a Unidirectional Link Rout- 
ing protocol, said request (1 8) for said multicast da- 

40 ta from said user stations (9) being filtered to pre- 
vent its transmission to other user stations (9). 

10. Apparatus for providing an Internet Protocol multi- 
cast service by a method as claimed in any preced- 
ing claim comprising transmitter means (1,10) for 
transmitting said multicast data (22) to said user 
stations (9) over said digital broadcast channel to- 
gether with said digital broadcast signals and mul- 
ticast data supplying means selectively responsive 
so to the reception of said request (18) for said multi- 
cast data from a plurality of said user stations (9) 
for supplying said multicast data (22) to said trans- 
mitter means (1 , 1 0), 

55 11. Apparatus as claimed in claim 1 0, wherein said mul- 
ticast data supplying means comprises a multicast 
server (7) linked to said transmitter means (1,10) 
through Internet infrastructure (4, 5), a gateway (6) 
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between the Internet (4, 5) and broadcast (10) In- 
frastructures and means for enabling transmission 
of said multicast data (22) selectively responsive to 
the number of requests (18) for said multicast data 
(22) received from said user stations in the broad- 
cast area served by said gateway (6). 
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